User: deprecate eraseCredentials#1739
Conversation
|
@VincentLanglet is that okay, or are the changes in the UserManager too much? |
| $password = $this->userPasswordHasher->hashPassword($user, $plainPassword); | ||
|
|
||
| $user->setPassword($password); | ||
| $user->eraseCredentials(); |
There was a problem hiding this comment.
hm but we still support Symfony 6.4 where eraseCredentials is not deprecated? 🤔 So I think completely removing the calls might break stuff for some people
| } | ||
| } | ||
|
|
||
| #[\Deprecated] |
There was a problem hiding this comment.
maybe it should be up to the users of this bundle to override the method on their user entity and add this attribute on their end? I feel like we cannot say if people are relying on this method to be called or not.
From what I understand Symfony will stop calling the method in case there is #[\Deprecated] present on the method.
Maybe we should do the same inside the UserManager classes? 🤔
| $password = $this->userPasswordHasher->hashPassword($user, $plainPassword); | ||
|
|
||
| $user->setPassword($password); | ||
| $user->eraseCredentials(); |
|
@dmaicher the problem: If the method is defined, and not deprecated, then Symfony will complain. In both cases, it is a dilemma |
|
@VincentLanglet your opinion to solve this dilemma? Have our user manager call the method causes the same Deprecation Message I'm trying to avoid |
|
@dmaicher I feel like it could be ok to change this with a note in the Upgrade note/release note that may introduce a minor bc break if someone override the method (?) |
yes I don't have a strong opinion on this. Fine for me. |
3 participants
Subject
I am targeting this branch, because should be BC. (I think)
Closes #1738.
Changelog